Loadstar 236/236.d81/t.inside dotb

Text File | 2022-08-26 | 9KB | 298 lines

u
           INSIDE DOTBASIC
           by Dave Moorman


    While I expect DotBASIC to become
my own programming environment of
choice, I created it for one central
purpose:

    To understand modern programming
concepts by emulating and implimenting
them.

    The project grew out of
discussions with my PC guru, Kevin
Barrows, about the ways and means of
6510 ML, BASIC 2.0, and Mr.Mouse.
Probably the single most seminal
comment came from Kevin when he
identified the "operating system" of
the raw C-64 as not so much an OS, but
a full implimentation of BASIC on all
upper levels.

    He is right. We do not have a
Command Line Interface (CLI). We have
a BASIC command that LOADs whatever it
is we want in memory. That is BASIC,
right off the bat.

    Rightfully so! This is, after all,
a 64K computer (with a 16K bag of ROM
and a 4K bowl of I/O). Memory is in
short supply and an independent
operating system is pricey. The C-64,
being eternally tied to the crippled
1541 and designd with a cassette tape
device in mind as the primary
peripheral, does not have any
boot-sector capabilities. One can turn
on a C-64 with no storage device
whatsoever and have everything
necessary to write and execute
software.

    (The 64K limitation is not, in and
of itself, reason enough to forego an
independent OS. CP/M was designed for
64K Z-80 computers and could handle
large programs and data by swapping
code and data to and from the disk.
Similarly, GEOS offers a working
Graphics User Interface operating
system by the same use of disk
"memory." The C-64's problem was the
rather slow disk access speed, which
early GEOS users discovered was
painfully slow. Many of you have
overcome such problems and make the
C-64/128 do everything you need done.)

    In my view, BASIC 2.0 has three
things going for it as a "proto-OS"/
language:

1. It is not bad, considering the
   limitations of the machine. Eight K
   of ROMis not large, so features had
   to be whittled down to the
   essentials.

2. It is free -- not only financially,
   but also memory-wise. Putting GEOS
   or any other OS on a C-64 consumes
   precious RAM, and may or may not
   utilize a fairly incredible library
   of useful routines in ROM.

3. It is adaptable. The 6510 processor
   allows full 64K of RAM. Moreover,
   according to Jim Butterfield, the
   designers of the C-64 were urged by
   software developers to include as
   many RAM vectors as possible so the
   ROM was not absolutely "hard
   coded." Anyone crazy enough can
   "improve" on the Machine that Jack
   Built!

(I have read how one can build a true
multi-tasking BASIC that will run two
programs at once. Pages 0 and 1 must
be swapped in and out of memory, and a
1Mhz processor moves a tad slow for
such to be very practical. But it
[can] be done!)

    In fact, such "possibility" is the
great fascination for me. We can do --
or at least "model" -- any
computational project on the C-64. The
results may not be completely
practical, but the intellectual
challenges are stimulating, to say the
least. And the knowledge attained is
enlightening. (While I find Windows 98
unconscionably flawed, I have great
respect for the programmers who made
it (almost) work.)

    So, could I approach a Visual
Design, Object Oriented, Event Driven
programming environment? Of course! I
already had many of the tools: BASIC
ROM, RAM Vectors, Mr.MOUSE, and my own
MR.MICK.

    The Event Driven concept (learned
while using Visual Basic on my Windows
PC) reminded me of something I had
ready many years ago (circa 1993) in

     [Advanced Machine Language]
      [Programming on the C-64]

by Lothat Englisch, published by
Abacus Software in 1984.

    Englisch showed how to use the NMI
timer to trigger a "behind the scenes"
GOSUB. The trick is to wedge code into
the STOP Vector -- which is called
during a program between BASIC
commands. The location of th
subroutine line number is found during
initialization and stored away -- and
the Event Sensing routine is wedged
into the STOP Vector. When the Event
happens, the current line number and
text pointer data are pushed onto the
processor stack, along with the GOSUB
token. The stored address is put into
the text pointer, and BASIC is
suddenly looking at the Subroutine!

    Though BASIC 2.0 requires a Main
Loop to keep it in Program Mode, Event
Driven programming is fairly easy to
impliment.

    For that Main Loop, I wanted to
use another idea Englisch included in
the book -- a REPEAT-UNTIL loop. This
also monkeys with the stack in much
the same way as the pseudo-GOSUB,
except the DO (I decided I like DO
better than REPEAT) stuffs its line
number and text pointer data onto the
stack. UNTIL does not pull the data.
It just uses it to take the program
back to the DO, until the condition is
True. Then the stack is flushed, and
life (and the program) goes on.

    The DO-UNTIL/WHILE code does not
do well from a SYS command. The
two-bytes in the stack for the RTS get
in the way. So, for this reason alone,
I needed some form of "real" command.

    There are three ways to use ML
routines in a BASIC program. The SYS
is nice, since it does not necessarily
upset Vector setting, something we
like at LOADSTAR!

    The second method involved three
Vectors. One wedges into the
Tokenizer, searches for new command
names, and puts new tokens in BASIC
memory. The second wedges in the List
Vector to display the new commands.
The third is a wedge in the Command
Vector that recognizes the new tokens
and sends the interpreter to their
respective code.

    What a bunch of work!

    The third method is to use a
Command Vector wedge to watch for a
particular character in the BASIC
code. If found, the following
character(s) represent a new command.
I chose a [period] for the identifying
character because it is unique, and
easy to read around.

    Hence -- DotBASIC!

    Then I decide on two-character
command names. These are harder to
read and remember than full command
names. But they have a real advantage.

    The addresses of the respective
routines are two bytes long. If I
search a table of two-character names
and find the one listed, the index can
point to a matching table of two byte
addresses.

    Before I got too far, I needed to
incorporate the Visual Design idea.
Here is where Mr.MOUSE comes in. Lee
Novak included defined screen Regions
that the mouse recognizes. The data
for these regions is in a 1 page block
of memory. Now, if that block was
included with a pre-designed screen,
and other data like line numbers,
hotkeys, and colors was in another
block of data, and these could be
saved and loaded into a program -- BY
GOLLY, we've got Visual Design!

    And I had Mr.MICK, the Mr.MOUSE
Image Construction Kit, all ready
working. One file type, FTS, includes
the Font, Screen, and Color
information. So I stretched it by two
pages and added Region and Event data.
At the time, I was thinking of calling
this language:

    Mouse Event Driven Development
         Language Experiment

                MEDDLE

    So the extension for the file was
.MED. Maybe I will change it with the
next version.

    And lastly, the question of Object
Oriented Programming was discussed
long and hard and far into the night
at the local truck stop coffee shop.
In Visual Basic and other OOP
languages, everything is an object
with properties.

    For instance, a sprite is a screen
object, but it also is a programming
object, with properties such as
position, color, width, priority,
image, etc. Now, in a full OOP, you
would name each sprite, then have
access to all the properties as
variables. Say the sprites name is
MAN. Then you could change the color
of MAN with:

        MAN.COLOR = white

    Every property has a name,
attached to the objects name with a
dot. I tried to make something like
this work, but the overhead became
just too pricey. You can approach OOP
in your own programming by using
arrays loaded with the register
information:

        SC(n) = Sprite Color
        FOR X=0to7:SC(X)=53287+x:NEXT

To change the color of Sprite 1:

        POKE SC(1),0

Which is easier -- and certainly OOP!

    In DotBASIC, we have Screen
Objects that are an